## Contents * [1 Standard di Pacchettizzazione](#Standard_di_Pacchettizzazione) * [1.1 Prototipo di PKGBUILD](#Prototipo_di_PKGBUILD) * [1.2 Etichetta del pacchetto](#Etichetta_del_pacchetto) * [1.3 Denominazione pacchetto](#Denominazione_pacchetto) * [1.4 Directory](#Directory) * [1.5 Compiti di Makepkg](#Compiti_di_Makepkg) * [1.6 Architetture](#Architetture) * [1.7 Licenses](#Licenses) * [1.8 Invio di pacchetti ad AUR](#Invio_di_pacchetti_ad_AUR) * [2 Linee guida supplementari](#Linee_guida_supplementari) * [2.1 CVS/SVN Packages](#CVS.2FSVN_Packages) * [2.2 Eclipse Plugin Packages](#Eclipse_Plugin_Packages) * [2.3 Gnome Packages](#Gnome_Packages) * [2.4 Haskell Packages](#Haskell_Packages) * [2.5 Java Packages](#Java_Packages) * [2.6 Kernel Module Packages](#Kernel_Module_Packages) * [2.7 Lisp Packages](#Lisp_Packages) * [2.8 OCaml Packages](#OCaml_Packages) * [2.9 Perl Packages](#Perl_Packages) * [2.10 Python Packages](#Python_Packages) * [2.11 Ruby Gem Packages](#Ruby_Gem_Packages) * [2.12 Wine Packages](#Wine_Packages) ## Standard di Pacchettizzazione **I PKGBUILD messi su AUR dagli utenti NON DEVONO riferirsi ad applicazioni già presenti nei repository ufficiali in nessuna circostanza. Eccezione a questa regola sono quei pacchetti compilati con particolari funzionalità abilitate e/o patch applicate differenti da quelle dei pacchetti ufficiali. In questi casi, la voce pkgname deve essere differente, in modo da comunicare chiaramente le differenze dai pacchetti presenti nei repo.** Nella realizzazione di pacchetti per Arch Linux, si dovrebbe **aderire alle linee guida per la pacchettizzazione** elencate qui sotto, soprattutto se avete intenzione di caricare il vostro PKGBUILD su [AUR](/index.php/AUR "AUR"). Fare riferimento inoltre alle pagine di manuale di [PKGBUILD](https://archlinux.org/pacman/PKGBUILD.5.html) e di [makepkg](https://archlinux.org/pacman/makepkg.8.html). #### Prototipo di PKGBUILD ``` # Maintainer: Your Name pkgname=NAME pkgver=VERSION pkgrel=1 pkgdesc="" arch=('i686' 'x86_64') url="http://ADDRESS/" license=('GPL') groups=() depends=() makedepends=() optdepends=() provides=() conflicts=() replaces=() backup=() options=() install= source=($pkgname-$pkgver.tar.gz) noextract=() md5sums=() #generate with 'makepkg -g' build() { cd $srcdir/$pkgname-$pkgver ./configure --prefix=/usr make } package() { cd $srcdir/$pkgname-$pkgver make DESTDIR=$pkgdir install } ``` Altri prototipi sono reperibili in /usr/share/pacman dai pacchetti di pacman e abs. #### Etichetta del pacchetto * I pacchetti non dovrebbero **mai** essere installati in `/usr/local` * **Non introdurre nuove variabili** negli script di compilazione `PKGBUILD`, a meno che il pacchetto non possa essere compilato senza, dato che queste potrebbero generare dei **conflitti** con le variabili utilizzate in makepkg. Se una nuova variabile è assolutamente necessaria, **sottolineare il nome della variabile** (`_`), ad esempio: `_customvariable=` AUR non può rilevare l'uso di variabili personalizzate e quindi non le può utilizzare per le sostituzioni. Lo si può osservare spesso, ad esempio in: `http://downloads.sourceforge.net/directxwine/$patchname.$patchver.diff.bz2` Tale situazione contrasta con l'effettiva funzionalità di AUR. * **Evitare** l'utilizzo di `/usr/libexec/` per nulla. Usare piuttosto `/usr/lib/${pkgname}/`. * Il campo `packager` del file meta pacchetto può essere **personalizzato** dal compilatore del pacchetto modificando l'apposita opzione nel file `/etc/makepkg.conf`, o in alternativa sovrascriverlo creando ~/.makepkg.conf * Tutti i messaggi importanti dovrebbero essere visualizzati (con echo) durante l'installazione utilizzando un file **.install**. Ad esempio, se un pacchetto ha bisogno di impostazioni extra per poter funzionare, tali indicazioni dovrebbero essere incluse. * Qualsiasi **dipendenza opzionale** non richiesta necessariamente per eseguire il pacchetto o con funzioni generali non dovrebbe essere inclusa; l'informazione dovrebbe invece essere aggiunta all'array **optdepends**: ``` optdepends=('cups: printing support' 'sane: scanners support' 'libgphoto2: digital cameras support' 'alsa-lib: sound support' 'giflib: GIF images support' 'libjpeg: JPEG images support' 'libpng: PNG images support') ``` L'esempio precedente è stato preso dal pacchetto **wine** in extra. Le informazioni "optdepends" vengono automaticamente stampate durante l'installazione/aggiornamento perciò **non** si dovrebbe mettere questo tipo di informazioni nei file .install. * Quando si crea una **descrizione del pacchetto**, non includere il nome del pacchetto in modo autoreferenziale. Per esempio, "Nedit è un editor di testo per X11" potrebbe essere semplificato con "Un editor di testo per X11". Tentare anche di mantenere le descrizioni a ~80 caratteri o meno. * Tentare di mantenere inoltre la **lunghezza della riga** nel PKGBUILD al di sotto dei 100 caratteri. * Laddove possibile, **rimuovere le righe vuote** dal `PKGBUILD` (`provides`, `replaces`, ecc.) * È pratica comune **preservare l'ordine** dei campi `PKGBUILD` come indicato sopra. Tuttavia, questo non è obbligatorio, in quanto l'unico requisito in questo contesto è la **corretta sintassi bash**. #### Denominazione pacchetto * I nomi del pacchetto devono essere composti solo da **caratteri alfanumerici**; tutte le lettere devono essere **minuscole**. * Le versioni del pacchetto **dovrebbero essere la stessa della versione rilasciata dall'autore**. Le versioni possono comprendere lettere, se necessario (ad esempio, la versione nmap è 2.54BETA32). **I tag della versione non dovrebbero includere trattini!**, ma solo lettere, numeri e punti. * Le release dei pacchetti sono **specifiche per i pacchetti Arch Linux**. Queste permettono agli utenti di distinguere le build del pacchetto nuove dalle vecchie. Quando viene rilasciata una nuova versione del pacchetto, il **conto della release parte da 1**. Poi, quando vengono eseguite correzioni ed ottimizzazioni, il pacchetto viene **rilasciato** nuovamente all'utenza di Arch Linux ed il **numero di release verrà incrementato**. Quando esce una nuova versione, il conteggio del rilascio viene azzerato a 1\. Il tag del rilascio dei pacchetti segue le **stesse limitazioni di nominazione che i tag di versione**. #### Directory * **I file di configurazione** dovrebbero essere messi nella directory `/etc`. Se c'è più di un file di configurazione, è consuetudine **utilizzare una sottodirectory** in modo da mantenere `/etc` il più pulita possibile. Utilizzare `/etc/{pkgname}/`, dove `{pkgname}` è il nome del pacchetto (oppure un'alternativa valida, per esempio apache usa `/etc/httpd/`). * I pacchetti dovrebbero seguire queste **linee guida delle directory generali**: | `/etc` | **File essenziali** di configurazione del sistema | | `/usr/bin` | Applicazioni binarie | | `/usr/sbin` | Binari di sistema | | `/usr/lib` | Librerie | | `/usr/include` | Header file | | `/usr/lib/{pkg}` | Moduli, plugin, ecc. | | `/usr/share/doc/{pkg}` | Documentazione delle applicazioni | | `/usr/share/info` | Informazioni file di sistema | | `/usr/share/man` | Pagine di manuale | | `/usr/share/{pkg}` | Dati delle applicazioni | | `/var/lib/{pkg}` | Memorizzazione applicazioni persistenti | | `/etc/{pkg}` | File di configurazione per `{pkg}` | | `/opt/{pkg}` | Pacchetti autonomi grandi, come Java, ecc. | * Il pacchetto non dovrebbe contenere le seguenti directory: * /dev * /home * /srv * /media * /mnt * /proc * /root * /selinux * /sys * /tmp * /var/tmp #### Compiti di [Makepkg](/index.php/Makepkg "Makepkg") Quando si utilizza makepkg per la compilazione di un pacchetto, quello che fa automaticamente è: 1. Verificare che i pacchetti **dependencies** e **makedepends** siano installati 2. **Scaricare i sorgenti** dai server 3. **Verificare l'integrità** dei file sorgente 4. **Decomprimere** i file sorgente 5. Eseguire tutte le operazioni necessarie di **patching** 6. **Compilare** il software e lo installa in una directory fake root 7. **Rimuovere** i simboli dai binari 8. **Rimuovere** i simboli di debug dalle librerie 9. **Comprimere** i manuali e/o le pagine info 10. Generare il **file meta pacchetto** che è incluso in ogni pacchetto 11. **Comprimere** la fake root nel pacchetto 12. **Memorizzare** i file del pacchetto nella directory di destinazione configurata (cwd è quella di default) #### Architetture L'array arch dovrebbe contenere "i686" e/o "x86_64" a seconda di qual è l'architettura di destinazione. È inoltre possibile utilizzare "any" per i pacchetti idonei ad entrambi i tipi di architettura. #### [Licenses](/index.php/Licenses "Licenses") L'array della licenza è in corso di implementazione nei repo ufficiali, e **dovrebbe** essere utilizzato pure nei propri pacchetti. Specificare come segue: * Un pacchetto licenze è stato creato in [core] e contiene licenze comuni in /usr/share/licenses/common, ad esempio /usr/share/licenses/common/GPL. Se un pacchetto è rilasciato sotto una di queste licenze, la variabile licenze dovrà essere impostata con il nome della directory, ad esempio license=("GPL") * Se la licenza appropriata non è inclusa nel pacchetto licenze ufficiali, si dovranno fare diverse altre cose: 1. I file delle licenze dovrebbero essere inclusi in /usr/share/licenses/$pkgname/, ad esempio /usr/share/licenses/dibfoo/LICENSE. Un buon modo per farlo è tramite: `install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"` 2. Se l'archivio dei sorgenti non contiene i dettagli della licenza, ma la si può ad esempio visualizzare su un sito web, copiarla in un file e inserirla. Ricordarsi anche di nominarla in modo appropriato. 3. Aggiungere "custom" all'array licenze. Opzionalmente, è possibile sostituire "custom" con custom:"name of license". * Una volta che viene utilizzata una licenza in due o più pacchetti in un repo ufficiale, incluso [community], diviene "common" * Le licenze MIT, BSD, zlib/libpng e Python sono casi particolari e non possono essere incluse nel pacchetto "common license". A causa della variabile della licenza, è trattata come una licenza comune (license=('BSD'), license=('MIT'), license=('ZLIB') or license=('Python')) ma per il bene del filesystem, è una licenza personalizzata, perché ognuno ha una propria linea di diritto d'autore. Ogni pacchetto licenze MIT, BSD, zlib/libpng o Python dovrebbe avere la propria licenza unica conservata in /usr/share/licenses/$pkgname/. * Alcuni pacchetti non possono essere oggetto di una singola licenza. In questi casi possono essere immesse più voci nell'array licenza, per esempio license=("GPL" "custom:some commercial license"). Per la maggior parte dei pacchetti queste licenze si applicano in diversi casi, invece di applicarle allo stesso tempo. Una volta che a pacman sarà aggiuntà la possibilità di filtrare i risultati in base alle licenze (in modo da poter scegliere ad esempio: "voglio solo software rilasciato sotto licenze BSD e GPL"), software rilasciati sotto licenze duplici (o multiple) saranno trattati da pacman con logica OR piuttosto che AND, in modo che pacman prenda in considerazione nell'esempio succitato tutti i software rilasciati almeno sotto una delle due licenze GPL e BSD, tralasciando tutti gli altri. * La (L)GPL ha molte versioni e permutazioni di tali versioni. Per il software (L)GPL, la convenzione è: * (L)GPL - (L)GPLv2 od ogni versione successiva * (L)GPL2 - (L)GPL2 solo * (L)GPL3 - (L)GPL3 od ogni versione successiva #### Invio di pacchetti ad AUR Si osservino le seguenti specifiche prima di inviare qualsiasi pacchetto ad AUR: 1. I PKGBUILD inviati **NON** devono assolutamente essere già presenti in nessuno dei repository binari ufficiali. L'unica eccezione a questa rigorosa regola può essere solo quella di pacchetti con caratteristiche o funzionalità extra, e/o con eventuali patch che li contraddistinguono da quelli ufficiali. In tali occasioni l'array pkgname dovrebbe essere diverso per specificare queste differenze. Esempio: Un PKGBUILD con uno schermo GNU inviato con la patch sidebar, potrebbe essere chiamato screen-sidebar ecc. Inoltre, l'array del PKGBUILD **provides=('screen')** dovrebbe essere utilizzato al fine di evitare conflitti con il pacchetto ufficiale. 2. Per garantire la sicurezza dei pacchetti inviati ad AUR si prega di **verificare** di aver compilato correttamente il campo `md5sum`. L'`md5sum` può essere generato utilizzando il comando `makepkg -g`. 3. Si prega di **aggiungere una riga di commento** nella parte superiore del file `PKGBUILD` che segue questo formato. Ricordarsi di mascherare il proprio indirizzo e-mail per evitare lo spam: `# Maintainer: Your Name
` Se si sta assumendo il ruolo di manutentore di un PKGBUILD esistente, aggiungere il proprio nome in cima come descritto sopra e cambiare il titolo del precedente Maintainer a Contributor: ``` # Maintainer: Your Name
# Contributor: Previous Name
``` 4. Verificare le **dipendenze** del pacchetto (ad esempio, eseguire `ldd` su eseguibili dinamici, controllare i tool richiesti dagli script, ecc). I TU raccomandano **vivamente** l'utilizzo dell'utilità `namcap`, elaborato da [Jason Chu](https://www.archlinux.org/fellows/#jason), per analizzare lo stato dei pacchetti. `Namcap` avviserà riguardo permessi errati, dipendenze mancanti, dipendenze non richieste, ed altri errori comuni. Si può installare il pacchetto `namcap` con `pacman`. Ricordare inoltre che `namcap` può essere usato per controllare sia file pkg.tar.gz che PKGBUILD. 5. Le **dipendenze** sono tra gli errori più comuni riguardo la pacchettizzazione. Namcap può aiutare a rilevarle, ma non è sempre infallibile. Verificare le dipendenze consultando la documentazione dei sorgenti e il sito web del programma. 6. **Non utilizzare replaces** in un PKGBUILD a meno che il pacchetto debba essere rinominato, per esempio quando *Ethereal* diventa *Wireshark*. Se il pacchetto è una versione alternativa di un pacchetto già esistente, usare conflicts (e provides se tale pacchetto è richiesto da altri). La differenza principale è che dopo la sincronizzazione (-Sy), pacman vuole subito sostituire il pacchetto installato, per trovare un pacchetto con il "matching" replaces da qualche parte nei suoi repository; conflicts d'altra parte viene considerato solo quando ha effettivamente luogo l'installazione del pacchetto, che di solito è il comportamento desiderato, dato che è meno invasivo. 7. Tutti i file caricati su AUR devono essere contenuti in un **file tar compresso** contenente una directory con il **`PKGBUILD`** e i **file di compilazione aggiuntivi** (patch, install, ...). ``` foo/PKGBUILD foo/foo.install foo/foo_bar.diff foo/foo.rc.conf ``` Il nome dell'archivio dovrebbe contenere il nome del pacchetto, ad esempio foo.tar.gz. Si può facilmente compilare un archivio contenente tutti i file richiesti utilizzando makepkg --source. Questo rinominerà un tarball $pkgname-$pkgver-$pkgrel.src.tar.gz, che può essere poi caricato su AUR. Il tarball **non dovrebbe** contenere nè il tarball binario creato da makepkg, né la filelist. ## Linee guida supplementari Si raccomanda di leggere per prima cosa le linee guida descritte sopra: molti concetti importanti sono spiegati in questa pagina e non verranno ripetuti nelle seguenti guide specifiche, che sono intese come un complemento agli standard elencati in questa pagina. #### CVS/SVN Packages Si prega di consultare [Arch CVS & SVN PKGBUILD guidelines](/index.php/Arch_CVS_%26_SVN_PKGBUILD_guidelines "Arch CVS & SVN PKGBUILD guidelines") #### Eclipse Plugin Packages Si prega di consultare [Eclipse plugin package guidelines](/index.php/Eclipse_plugin_package_guidelines "Eclipse plugin package guidelines") #### Gnome Packages Si prega di consultare [GNOME package guidelines](/index.php/GNOME_package_guidelines "GNOME package guidelines") #### Haskell Packages Si prega di consultare [Haskell package guidelines](/index.php/Haskell_package_guidelines "Haskell package guidelines") #### Java Packages Si prega di consultare [Java package guidelines](/index.php/Java_package_guidelines "Java package guidelines") #### Kernel Module Packages Si prega di consultare [Kernel module package guidelines](/index.php/Kernel_module_package_guidelines "Kernel module package guidelines") #### Lisp Packages Si prega di consultare [Lisp package guidelines](/index.php/Lisp_package_guidelines "Lisp package guidelines") #### OCaml Packages Si prega di consultare [OCaml package guidelines](/index.php/OCaml_package_guidelines "OCaml package guidelines") #### Perl Packages Si prega di consultare [Perl package guidelines](/index.php/Perl_package_guidelines "Perl package guidelines") #### Python Packages Si prega di consultare [Python package guidelines](/index.php/Python_package_guidelines "Python package guidelines") #### Ruby Gem Packages Si prega di consultare [Ruby Gem package guidelines](/index.php/Ruby_Gem_package_guidelines "Ruby Gem package guidelines") #### Wine Packages Si prega di consultare [Arch wine PKGBUILD guidelines](/index.php/Arch_wine_PKGBUILD_guidelines "Arch wine PKGBUILD guidelines")